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ABSTRACT 


In this thesis, we have considered the problem <£ updating 
a data base system based on relational model. Data base is im- 
plemented on TDC-316 computer available in the Computer Centre, 
Indian Institute of Technology, Kanpur. This forms a part of a 
larger project involving building, retrieval, and security of 
data base. 

In updating we have considered the following three opera- 
tions - 

(l ) Insertion 

(2) Modification 

( 3 ) Deletion. 

Each o-p these three operations can be performed on a single 
relation or the whole data base. Algorithms for these operations 
have been designed and implemented in Basic Assembly Language. 
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1 . INTRODUCTION 


Information updating system works on a personnel data base develop- 
ed at Indian Institute of Technology, Kanpur as an M.Tech. project on 
TDC-316 computer. A personnel data base is a data-base which stores 
information of persons and in our case persons are army officers. Whole 
data base consists of 80 fields and 12 relations, each relation being 
in third normal form. 

T he values of different fields in a personnel data base are sub- 
ject to changes from time to time. Moreover a situation may arise when 
new records are to be added to or records already existing are to be 
deleted from a single relation on the whole data base. These types of 
operations are called updating. Thus updating consists of three opera- 
tions, nmnely - 

(l ) Deletion 

(2 ) Modification 

(3 ) Insertion 

Deletion 

In this operation, all the informations of user specified army 
officer (s) are deleted from a single relation or from the whole data base. 
Modification 

In this operation, values of sane fields of sane persons, specified 
by user are modified in a single relation or whole data base without 
creating any new records. 

Insertion 

In this operation, informations of sane new persons, specified by 
user are inserted in a single relation on vfoole data base in the fora 
of new records. 
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When updating is based on a single relation vve call it " single 
relation updating" and when it is based on all the relations present 
in data base we call it "group relation updating*" 

To illustrate updating operation let us consider a data base having 
two relations as follows: 


Relation R1 


Personnel 

Ho. 

Rank 

Qualifi- j 

cation J 

| IC-00005 

CAPT 

i 

_B.Sc. 

1 IC-00006 

4 l 

i 

MAJOR 

33 . A . 

5 | 

; IC-0001 0 

? 

CAPT 

33. B. 

! 


Relation R2 


! Personnel | 
1 lo. 

Languages l 

Known ' 

— | 

Service Experience j 

i 

IC-00005 

' \ 

Hindi j 

5 

IC-00005 

1 

Bengali 

5 

! 

IC-00006 

Tamil 

10 

IC-0001 0 

Telugu 

8 

IC-0001 0 

Malayalam 

8 

IC-0001 0 

1 

Panj abi 

i 

8 

i 

i 


1 . Delete 

(a) Group Relation Deletion : Let us assume that an army officer 
having personnel Ho. IC-0001 0 resigns from army and all his informations 
therefore, are to be deleted frcm data base* These relations after dele 
tion will look like as follows: 
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Relation R1 Relation R2 


Personnel j 
No. 

Rank 

Qualifi- 

cations 


Per some 1 
No. 

Lunguague s 
Known 

Service 

Experience 

IC-00005 

CAP! 

3. Sc. 


ic-00005 

Hindi 

5 

IC-00006 

MAJOR 

B.A. 


IC-00005 

Bengali 

5 



i 

? 


IC-00006 

Tamil 

10 


(ii) Single Relation Deletion : If the informations of personnel 
No, IC-00010 is deleted from only relation 2 data base after deletion 
will look like as follows: 


Relation R1 


'Personnel 

Rank 

Qualifi- 

No. 

cations 

1 

, ic-00005 

CAPT 

ni r ■ - - i " n ■ 

B.Sc. 

IC-00006 

MAJOR 

B •Jri • 

IC-0001 0 

J i 

CAPT 

B.3* 

i 


Relation R2 


Persomel 

No. 

Languages 

Known 

Service j 

Experience 

IC-00005 

I 

Hindi 

5 

IC-00006 

Bengali 

5 

IC-00006 

Tamil 

10 

; ! 


2. Modification 


(i) Group Relation Modification : If it is observed that rank, 
qualification, service experience of personnel No. IC-00006 needa modi- 
fication, the operation involved is group relation modification because 
the fields to be modified exist in more than one relation. If the rank 


becomes captain, qualification becomes M.A., and service experience 


becomes 12 years and the relations will look like - 


Relation R1 


xv 

Persomel 

No. 

l 

Rank ■ 

Qualifica- : 
tions j 

IC-00005 

CAPT 

1 

B.Sc. i 

1 
i 

IC-00006 

MAPI 

i 

M.A. 

IC-0001 0 ; 

CAPT 

B.E . 


Relation R2 


Persomel i 
No. : 

Languages 

Known 

Service 

Experience 

IC-00005 

Hindi 

5 

IC-00005 

Bengali 

5 

IC-00006 

Tamil j 

12 

IC-00010 

Telugu 

8 

IC-00010 

Malay al am j 

8 

IC-00010 

Punjabi 

8 
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(ii) Single Rel abion Modification ; If the fields to be modified exist 
in a single relation the operation involved is single relation modifica- 
tion. If only rank and qualification of Personnel Ho. IC-00006 need to 


be modified, relation R2 in the above case will remain unaltered. 
3 . Insertion 


(i) Group Relation Insertion: If information of a new person having 
Personnel Ho. 10-00015, say, is to be inserted relations get modified to: 


Relation R1 


Personnel 

No. 

Rank 

Qualifi- 
cations | 

IC-00005 

CAPT 

B*Sc# 

IC-00006 

MAJOR 

B. A. 

IC-00010 

CaPT. 

B.B. 

1 

! IC-0001 5 

1 

MAJOR ; 

M.Sc. 


Relation R2 


'Per s cnnel 
No. 


Service 

Exjpa rience 

IC-00005 

Hindi j 

5 ! 

IC -00005 

Bengali j 

5 i 

IC-00006 

Tamil ! 

10 

; IC-00010 i 

Telugu j 

8 

' IC-00010 

Malayalam 8 1 

j IC-00010 

Punjabi . 

8 1 

IC-0001 5 

lashmirij 

0 1 

1 


t 


This is group relation insertion because records have been inserted 
in more than one relation. 

(ii) Single Relation Insertion : If Personnel No. IC-00006 learns 
one more langujge only Relation 2 gets modified to - 


Personnel 

No. 

languagues 

Known 

Service 

Experience 

IC-00005 

Hindi 

5 ! 

IC-00005 

Bengali 

5 j 

IC-00006 

Tamil 

10 

IC-00006 

Mad ayalam 

10 

IC-0001 0 

Telugu 

8 

IC-0001 0 

Malayalam 

8 

IC-00010 

i 

Punjabi 

8 

: ! 


This is single relation insertion 
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Special Cases - 

(i) If value of a field for any personnel number is to be deleted 
the operation involved is modification. For example, if we want to 
delete value of field "RA1IK" for Personnel Ho. IC-00005 we have to modi- 
fy this record by putting blanks as value of this field. Relation R1 
after this modification takes the form - 


Personnel 

Ho. 

Rank 


cations ! 

IC-00005 

ffl — -M 

J 

B. Sc. 

IC -00006 

MAJOR 

B.A. 

IC-0001 0 

CaPT 

t 

]B ♦ j 


(ii) If a field is such that it can have more than one vaLue for the 
same personnel number (for example, "Languages Known") and if it is to 
be modified the operations involved are deletion and insertion. For 
example, if personnel number IC-00005 knows language URDU instead of 
HINDI then all the records for that personnel number are to be deleted 
from that relation first and then new records are to be inserted. After 
this operation R2 takes the form - 


1st Stage (after deletion 2nd Stage (After insertion) 


■Personnel] Languages 
Ho. 1 Known 

Service j 

Experience ! 

Personnel 

Ho. 

Language s 
Known 

Service 

Ex]£ rience 

IC-00005 

U — AS 

: 

5 ! 

IC-00005 

Urdu 

5 

IC-00005 

U — M 

5 


IC-00005 

Bengali 

5 

IC-0Qp06 

Tamil 

10 


IC-00006 

Tamil 

10 

IC-0001 0 

Telugu 

8 


IC-0001 0 

Telugu 

8 

IC-0001 0 

Malayalam 

8 


IC-0001 0 

Mai ayalam 

8 

IC-0001 0; 

Punjabi 

- 1 

8 


IC-0001 0 I 

Punjabi 

8 


This operation will be called as special-modification operation, 



2. DESCRIPTION OP DATA STRUCTURES 


Data structures for updating operation are built based on the 
following assumptions: 

(i) Out of three operations involved in updating, namely 
insertion, modification and deletion only one can be 
performed at a time except in the case of special- 
modification operation. 

(ii) Any No. of fields can be updated at a time depending 
on the size of data structures. Size has been allo- 
tted such that a maximum of 40 fields can be updated 
at a* time. 

(iii) Any number of person’s informations can be updated 
at a time depending on the size of a data structure 
USPITB to be explained latter. 

(iv) Updating is performed either on a single relation or a 
group of all the relations having the same primary key. 

Por example , if relations 3 >5 and 9 are having same 
primary key, updating of relations 3 and 5 but not 9 is 
not possible at a time. Relations 3 and 5 have to be 
updated separately as single relation updating. This 
type of assumption is quite reasonable due to the fact 
that when some field is updated, our aim will be to 
update all those relations in the whole data base where- 
ever that field occurs. Updating some relations and not 
the rest may create discrepancy in data base. 

(v) If user specifies seme fields for updating all of which 
are not present in a relation, processing will not be 
deleted but all those fields which are present will be 
updated. 

(vi) In case of single relation updating user has to specify 
the relation but not in group relation updating. 

Por updating operation user has to specify a file called user file. 
A sample user file is given in Figure 1 


Primary Key 


Fields to be updated 


Personnel No. 


Rank 


Salary 


Qualification 


10-00005 
IC -00008 


CAPT. 

* 


1500 

* 


* 

M.Tech. 


Figure 1 


6 
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Each column x>£ this file represents a field to be updated except the 
primary key. Each row is a record of user file. A special character as 
a value of c field against a personnel number indicates that this field 
need not be updated for tint person. 

In s ingle relation updating, all the fields specified in user's file 
will be updated only in the specified relation. In group relation updating 
all the fields specified in user's file will be updated in all those rela- 
tions whose primary key is the same as the primary key of user's file. 

In case of deletion user's file consists of only primary key. 

All thefields of user's file are specified by user according to the 
following format: 

LEVEL ]6 EIELL NAME HELD CODE FORMAT. 

LEVEL = 22 for primary key 
= 44 for filler field 
=02 _ for ordinary field 

=0 to indicate end of field specification. 

Field can be specified either through keyboard or card reader. 

Example 


22 $ PMJI1 ]6 FI )6 X* 8. 

44 ]6 FILLER ]6 X*4- 
02 $ RAM J6 F3 ]6 X*6. 

44 ]6 FILLER ]6 X*4- 
02 ]6 SALARY )6 F9 ]6 9*6. 
44 ]6 FILLER ]6 X*6. 

02 ]6 QUALE J6 F25 % X*S. 

00 . 


Figure 2 

Inform itions of above user's file fields are stored in the following 


data structures: 



8 


Data. Structure FLD : 

It stores alphabetic part of field code in one byte. Size of the 
array is 40 bytes. 

Data Structure IffPIiCD: 

It stores numeric part of field code in one byte. Size of the 
array is 40 bytes. 

Data Structure IHE'DGT: 

It stores length of field in one byte. Size of the array is 40 
bytes. 

Data Structure PI ST; 

It stores distance of this field from the beginning Of a user file 
record in one byte. Size of array is 40 bytes. 

Data Structure LDIST; 

It stores distance of a field from the beginning of a user file 
record after removing fillers in one byte. Size of array is 40 bytes. 
Data Structure POEM A: 

It stores format code of the fields specified in user's file in one 
word. Size of array is 40 words. 

Example 

is 

When fields are specified in Figure 2 contents of different data 
structures will be as follows - 


FDD 

IRFLCD 

IMFLGflD 

DIST 

DDIS1 

FORMA 

F 

1 

8. 

0 . 

0 . 

030010 

F 

3 

6. 

12. 

8. 

0*20006 

F 

9 

6. 

22. 

14- 

000006 

F 

25 

8. 

34* 

20. 

03001 0 


Figure 3 
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These data structures are printed in keyboard for user verification. 
Data Structure USFLTB (User File Table): 

This data structure stores values of fields specified in user file 
after removing fillers. Each byte stores one character and size of 
USFLTB is octal 4000 bytes. If average length cf a record in user's file 
is 40 bytes informations of 50 persons can be updated at a time. 

Field values are specified either through keyboard or card reader 
depending on user's choice. Each record must be embedded with fillers 
as specified in field specification of user's file. These values are 
stored in USFLTB after removing fillers. Necessity of storing vdnes in 
some area in main memory arises due to the fact that more than one rela- 
tion may haveto be updated in case of group relation updating. An example 
of how to specify values of fields corresponding to Figures 1 and 2 is as 
follows - 
Record No. 1 

ic-oooo5#0#capt >MMtf 1500;$ MMM MMMM 

Record No. 2 

ic-00008 MM MMM MM MMM MMM M.Tech.tf 

When these records are specified through keyboard each record must 
be terminated by a carriage return and when these records are specified 
by punched cards each record must start from a fresh card and one record 
may be punched in 5 cards at maximum, maintaining the correct size of 
fillers. Each record after checking the correct presence of fillers 
and correct record length is stored in USFLTB after removing fillers, 
in example of how the above two records will be stored in USFLTB is 
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as follows - 

IC-000050AM .%\ 5 00^*^^^10-00008 • To eh .]6 

So far, the data structures nece ssary for updating operation hare 
been described. These data structures are built before the actual 
execution of updating operation starts. Now other data structures 
which are built during, the execution phase will be described. 

Data Structure PDELaG 

Before execution of updating operation starts, it must-be checked 
whether the fields specified in user file are present in a relation. 

In case of single relation updating, it is expected that all the fields 
specified in user's file are present in the specified relation to be 
updated. If it is not, it must be indicated by flags which fields are 
common between user specified file and the specified relation and only 
those fields will be updated. This is valid for group relation updating 
also* 

In this case, all the fields which are common between user speci- 
fied file and a relation are updated. When some field is found to fe 
canmon, corresponding byte in PDPLAG data structure is set to 1 , else 
it is cleared. When there is no field common this relation is skipped. 

To check which fields are common between user specified file and 
a relation is done with the help of a data structure FD1IST (field list). 
IDLIST is constructed while building the data base. It stores the follow- 


ing informations: 
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(i) Field codes of fields present in a relation 

(ii) Distance of a field from the start of a record in 
a relation. 

(iii) Format code of field. 

Sizu of fDFLaIt -*- s 40 bytes. One byte is reserved for one field. 
Data Structure CIvlFhDS (common Field Di stance ) 

This data structure stores distance of a field from the start cf 


a record in a relation, for those fields whose FDFLAG byte is set. d hen 
a field is found to be common between user specified file and a relation, 
the distance of the field from the start of a record in that relation 
is read from FD1ISI and is stored in the corresponding byte cf CMFIDS. 
Size of CMFLDS data structure is 40 bytes. 

Example 


Let us assume FD1IST contains the following informations: 


Bel. Ho. 


Field code Distance 


Format 


1 1 

1 5 

1 19 


0 03001 0 

8 020005 

14 01 01 02 


4 

4 

4 


1 

3 

25 


0 03 0006 

8 050008 “ 

1 4 03001C 


6 

6 


1 

25 

9 


0 03001 0 

8 030010 

1 6 0300G6 


Assuming the user file as in Figure 1 with specified fields 
as in Figure 2, contents of different data structures will be as 


follows : 
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While Updating Eel. 1 




IHFLCD 


FUll&Cr 

OMFIDS 

1 


1 

0 

3 


0 

- 

9 


0 

- 

25 


0 

— 

While Updating Eel. 4 




IMPLCD 


FDSWJ 

CitFLUS 

1 


1 

0 

3 


1 

8 

9 


0 

— 

25 


1 

14 

While Updating Eel. 6 




IJJPLCD 


ITELAfi 

CMETiDS 

1 


1 

0 

3 


0 

— 

9 


1 

16 

25 


1 

8 

Following data structures, 

constructed by BUILD subroutine. 

while building the relations, are repeatedly used in updating opera- 
tion. Hence a brief description of these data structures are given 

below. 




RelatL on Dire ct ory (RELDIR ) : 



This data structure 

stores 

various 

informations about a relation 

and is stored columnwise 

in memory. A 

sample relation directory is 

shown below in a tabular 

form. 

Ii-th row of this table corresponds 


to Helation No. 1. 
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RELMJM 

REDID 

FiAIUX 

"hied" 

TOTREC 

KEYRP 

E!JKRP 

CRCEO 

LEGTRC 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

NAME 

R1 

27000 

3 

1000 

El 

3 0006 

0 

I 

26 

QUALE 

R2 

27040 

2 

500 

El 

3 0006 

0 

12 


Various columns of this table hc.ve the following interpretations: 

RELNUH : It stores 8 character long nmae given to u relation. 

EELID : It stores internal identification number given to a relation* 

EMIHX : It stores the starting address of Primary Index Table stored 

in memory corresponding to a relation. 

HIED : It stores number of records in Primary Index table of a relation. 

TOTREC : It stores total number of records stored in a relation. 

KEYIiP : It stores internal identification number ofpMmary key of a 

relation. 

EMKRP : It stores format of primary key. 

CRCHO : It stores overflow cylinder number of a relation. This is to 
be constructed only by insertion operation. 

LECTRC : It stores record-length of a relation. 

Primary Index Table 

Corresponding to each relation one primary index table is maintained. 
This table stores informations of the type, which are the cylinders used 
to store the relation, highest primary key value in each cylinder and 
number of records in Secondary Index Table corresponding to each 
cylinder. This table is stored row-wise in core memory. A sample 
primary index table is as fdLlows: 
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Highest key in 

the cylinder 
" ' 

Cylinder 

Ho. 

Ho. of records in j 

Secondary Index TabLe 1 

IC-0001 0 

1 

13 

i 

±^_J 

100 

1 

IC-00300 | 

1 

1 20 

100 

IC-00350 i 

11 

! 44 


I 


Secondary Index Table 

Por each cylinder, one secondary index table is maintained in its 
Oth surface. 'This table stores informations of the type, which sec- 
tors in the cylinder are used to store records, highest primary key 
value in a sector and number of reoords stored in it. This table is 
stored row-wise. A sample secondary index table is as follows: 


1 No. of records 

Highe st Primary Key i 

Address of 

in sectors 

in sectors 1 

sectors 

10 

IC-0001 3 

■" ■ 1 1 1 11 " 1 

41 

i 

j 

8 

IC-00025 , 

* 

1 

42 j 

0 ! 

| 

45 1 


Overflow Area 

Overflow area is a collection of c few cylinders an disk. The 
necessity of overflow urea arises in insertion operation. While 
inserting a new record, it may happen th_t according to primary and 
secondary index tables either no sectors, no cylinder is allotted to 
that record or some sectors, some cylinder is allotted but no space 
is actually available in that sector, when no space is allotted, 
naturally record has to be stored in the last sect or or a fresh 
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sector on even a fresh cylinder, if necessary. But if a sector is 
allotted, it has to be stored only in th t sector to maintain the 
characteristics of Bata Base that recurds are s.orted before being 
stored. If space is available in the allotted sector there is no 
problem but if it is not available there .ore two alternatives. 

First alternative is to move a few records fruu this sector to next 
sector and make space available. But this process is very time 
consuming and dL so tedious due to the fact that the immediate next 
sector may not have space available in it. In that case, record 
has to be moved from one sector to the next sector until some sector 
is found where some space is available, Corresponding secondary index 
table will hive to be changed drastically. Moreover, if it is observed 
that no sp ace is available in the whole cylinder then transfer of 
records from one cylinder to another will be necessary until a cylin- 
der i • found where space is available. This will cause changes in 
primary index table also. If no such cylinder is found the record is 
to be stored in a fresh cylinder and primary index table will have 
an extra entry corresponding to this cylinder. 

Second alternative is that when it is found for the first time 
that record does not get enough space in the allotted sector, an 
empty cylinder is found out and it is allotted to the corresponding 
relation as an overflow area. Thus each relation will have at most 
one cylinder as overflow area and this overflow cylinder will be . 
allotted to the relation only viien such an overflow situation takes plac 
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As soon ns, an overflow cylinder is allotted to a relation this cy- 
linder number will be stored in corresponding entry of this relation 
in CRCNO data structure of relation directory. In first two bytes of 
first sector of overflow cylinder highest sector number of overflow 
cylinder is stored which stores records. Recurds are stored in 
overflow cylinder sx anting f ran seco nd Sector. V/hen an overflow 
occurs a free sector of overflow cylinder is f oundout and its 
surface-sector number is stored in last 2 bytes of the original 
sector from which overflow has occurred, for subsequent overflows 
in this sector, this will act as a pointer to the overflow sector. 

In this scheme, corresponding to each sector in original cylinder 
one sector is allotted as an overflow sector. Thus during insertion 
operation if overflov/ occurs frcm more than 99 sectors of a relation, 
operation stops and DBA has to re-arrange his DATA BASE before any- 
more records can be inserted. On the other hand, if there is an 
overflow in the overflow sector itself, next available sector in 
overflow cylinder will be allotted as overflow area to this overflow 
sector .and process becomes recursive. 

An important point to note is that we are assuming that last 
2 bytes of each sector are free so that a pointer can be stored here. 
This is consistent with BUILD subroutine which builds the whole data 


base. 



3. CONSTRUCTION OP Data structures 

Construction of data structures is the initial phase of updating 

operation. In this chapter, its algorithm is given. Various subroutines 

needed for bhis purpose are briefly described at the end of this chapter. 

Algo rit hm 

Step 1 : Specify operation. 

Step 2: Is it updating? If yes go to Step 6 el se go to Step 3. 

Step 3 • Is it retrieval? If yes go to Step 4 else go to Step 5* 

Step 4: Stop. 

Step 5= Is it DBA operation? If yes go to Step 4 else go to Step 1. 

Step 6: Give input maximum for the fields of user’s file. 

Step 7: Is input medium card-reader? If yes go to Step 9 else go to 
Step 8. 

Step 8: Is input medium keyboard? If yes go to Step 9 else go to 
Step 6. 

Step 9: Specify user file fields through specified input medium with 
primary key as first field and scan it. 

Step 10:1s BEVEL = 0? If yes go to Step 23 else go to Step 11. 

Step 11 :1s LEVEL = 22? If yes go to Step 12 else go t o Step 14* 

Step 12:1s primary key already specified? If yes go to Step 13 else 
go to Step 19. 

Step 13=Give message ’’Primary Key is Specified more than once, field 
ignored". Go to Step 9. 

Step 14:1s primary key already specified? If yes go to Step 16 else 
go to Step 15. 

Step 15: Give message "Primary key not yet specified". Go to Step 9, 
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Step 16: Is LEVEL = 44? If yes go to Step 22 el as go to Step 17* 

Step 17: Is LEVEL = 2? If yes go to Step 19 elsego to Step 18. 

Step 18: Give message "Illegal level number, field ignored". Go to 
Step 9. 

Step 19: Transfer alphabetic part of field code to ELD, numeric port 
to IMFLCD, format to EOEMA. 

Step 20: Eind out length of field and transfer it to IHELGT. Transfer 
actual distance of field to DIST and distance after removing 
fillers to LDIST. 

Step 21 : Update total length of user-file-record. Go to Step 9. 

Step 22: Eind out length of filler field. Go to Step 21. 

Step 23: Total number of fields specified = 0? If yes go to Step 9 
else go to Step 24- 

Step 24: Print contents of data structures ELD, IHELCD, IxlELGT , DIST, 
LDIST and EDEMA. Check whether there is any field specified 
such that it does not exist in EDLIST or any field duplication 
or wrong format specification. If yes set ERRELG. Go to 
Step 25. 

Step 25: ERRELG is set? If yes go to Step 9, else go to Step 26. 

Step 26: Specify input medium, for specifying records uf user’s file. 

Step 27: Specify a record of user’sfile through specified input medium. 

Step 28: Check whether record length of specified record is correct. 

If yes go to Step 30, else go to Step 29. 

Step 29: Give message "Record length incorrect. Specify this record 
again". Go to Step 27. 

Step 30 : Check whether fillers .re properly placed. If yes go to Step 
32, else go to Step 31. 

Step 31 : Give message "Fillers are not properly placed". Specify this 
record, again. Go to Step 27- 

Step 32 : Store the record in USELTB after removing fillers. Increment 
total number of records in user’s file by 1 . 
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Step 33: End of user’s file? If yes jump to processing phase, else 
go to Step 27. 

End cf Algorithm.. 

To implement the above algorithm following subroutines have been 
written : 

(1 ) Subroutine DQOEV (decimal conversion) - 

This subroutines transfers contents of a word to buffer of 
size 6 bytes to print the content in decimal notation. 

Example - 

JM3 R2, DGONV 
./OHD ROM 
TOED BOF+6 

RUM : WORD 50. 

BUF : WORD 6,0,6 

. = .+6 

(2) Subroutine QCORY (Octal conversion) - 

This subroutine transfers contents of a word to a buffer of 
size 6 bytes to print the content in octal notation. 

Example - 

JMS R2, 0C01W 
WORD ROM 
TOED BUF+6 

RU M : JOED 50. 

BUF : TOED 6,0,6 

. = .+6 

(3 ) Subroutine FICHEK (field check) 

This subroutine checks validity of field codes specified in user 
file. Field codes must have F as alphabetic part and non-zero positive 
integer not mare than 80 as numeric part. If there is any field code 
duplication their formats must be different 1$ cause some field may 
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occur in 2 relations in two different formats. If any of the above 
mentioned conditions are violated for any field specified in user’s 
file ERRFLG flog is set. Calling instruction, JMS R3, FLCHEK. 

( 4 ) Subroutine FMCHBK (format check) - 

This subroutine checks whether a field specified in user’s file 
is presrnt in FDLIST with the sincified format. If not, it sets a 
flag ERRFLG. 

Calling instruction, JMS R3, FMCHEK. 

( 5 ) Subroutine FMLNGT (format length) 

This subroutine accepts format code of a field in octal as 
input and outputs its length. 

Example : 

JMS R5, FMLNGT 
WORD FORMAT 
WORE LENGTH 
FORMAT : WORD 030010 
LENGTH : .=.+2 

(6) Subroutine PRUSEUL (Print user file) 

This subroutine prints the contents of different data structures 
FLD, INELCD, INFLGT, BIST, LDIST and FORMA for manual verification 
calling instruction, JMS R3, PRUSPUL. 

( 7 ) Subroutine BLANKB (blank buffer) 

This subroutine puts blanks in a buffer - 


Example : 


JMS R2, BLANKB 
WORD BOF+6 
WORD SIZE 

BUF : WORD 100., 0, 100. 

. = .+ 100 . 

SIZE : WORD 50. 


Contents of first 50. bytes of BUF starting from BJF+6 will be blanks. 
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(8) Subroutine CHEKBL (check blank) 

It checks whether contents of a certain area, are blank or not. 
if not it sets fl_g J2RPLG1 . 

Example : 


JUS R2, CHEtKEIi 
WORD HJF+6 
WORD SIZE 
SIZE : WORD 2 
HJj? : WORD 100,0,100 
. = .+100 

If contents of HJE+6 and BUP+7 are blanks ERFLG1 is reset else 
it is set. 

(9) Subroutine BILCHK (filler check) 

This subroutine checks whether fillers are properly placed in 

/ 

a user file record. If not, it sets a flag ERBLG1 . Calling instruc- 
tion JMS R6, FHiCHK. 

(lO) Subroutine STORE 


This subroutine stores user's file record frcu. a buffer to 
USPLTB after removing fillers - 
Example - 


TSR USPITB, LOC 
JMS R6, STORE 
WORD IOC 
LOC : WORD 0 

(ll) Subroutine DATAIN (Data Input) 

Calling instruction, JMS R5, DaTaISF. 

This subroutine accepts user 's file redords. It calls following 


two subroutines 
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(12) Subroutine KBDIxT (input through keyboard) 

It accepts user’s file records through keyboard calling instruc 

tion: 


JUS B3, KBDI1T. 

( 13 } Subroutine CARDIN (input through c ard-reader) 

This subroutine acce pfcs user file records through c ard-reader. 
Calling instruction JMS R3 , CARDIE. 
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4. PROCESSING- PEASE 


When, nil the data structures h-ve been built, processing of ectuaL 

up d- tin;-, op r-tion starts. Here user has to specify vfhat tJT?e of updating 

operation it is, -foether insertion, deletion or modi "icstion. 41 so he has 

to specify wh -ther updating is based on a single rel-tion or group of r®la 

tions. I" it is single relation, it must be checked from PD1IST whether 

the primary key and its form t are correctly specified and other fields 

specified in user file do at all exist .in the specified relation. PlELAG- 

and CLIFIiDS data structures are cor©epondingly built. Various informations 

regarding the specified relation are read from redo t ion directory. Delete, 

Insert or Modify subroutine is called de pending on whether the updating 

operation is deletion, insertion or modification respectively. 

On the other hand, if updating is based on group of relations, all the 

relations are found out from relation directory whose primary key is the 

some as primary key of user file and the pocess of single relation updating 

is repeated fear all these relations. 

Algorithm for processing phase is as follows - 

Step 1 : C-leul-te primary and secondary indextable record lengths. 

Initialize BSLOCP to the starting address of USPLTB. Specify 
hither up! nting operation is insertion, deletion or modifica- 
tion. 

Step 2: Is updating operation Insertion? If yes goto Step 5 else go to 
Step 3. 

S 

Step 3: Is updating operation deletion? If yes go to Step 5 else go to 
Step 4. 

Step 4: Is updating operation modifention? If yes go to Step 5 else go 
to Step 1 . 
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Step 

' 5: 

Step 

6: 

Step 

7 ; 

Step 

8: 

Step 

9: 

Step 

10: 

Step 

11 : 

Step 

12: 

Step 

13 = 

Step 

14: 

Step 

15: 

Step 

16: 

Step 

1 7 : 

Step 

18: 

Step 

19: 


Step 20: 


Specify whether updating is based on a single rel- tion or group 
O' 1 ' rel~tions. 

Is&pdating based on a single reltion? If yes go to Step 8, 
else go to Step 7. 

Is updating b^sed on group of relation s? If yes go to St»p 35, 
else go to Step 5. 

Specify r >1 'tion no- and store it in RELCD, 

Is specified relation no. RELCD less than 1 or greater than 39? 

If yes go to Step 10, else go to Step 11. 

Give message "Relation Ho. wrongly specified, specify it again". 

Go t o Step 8. 

Check from relation directory whether relation RELCD exists in 
Data Base. If yes go to Step 13, else go to Step 12. 

Give message, "Specified relation does not exist in Data Base, 
specify it again.". Goto Step 8. 

from relation directory check whether primary key of user file 
is aaorrectly specified. If yes, go to Step 15, else go to Step 14. 

Give message "Primary key of user file does not matdfa." Go to 
Step 8. 

from relation directory check whether form't of primary key of 
user file is correctly specified. If yes go to step 17, else 
go to Step 16. 

Give he ssage, "Form t of Primary Key does not match". Go to Step 8, 

Check whether relation RELCD exists in FDLIST. If ye° go to 
Step 19, else go to Step 18. 

Give message, "Relation d$s not exist in FDLIST. Relation 
directory and FDLIST are inconsistent." Go to Step 5. 

Check from FDLIST whether there is any field common between user 
file and the specified relation. If yes, goto Step 21, sLse 
go to Step 20. 

Give message, "No common .field between user file and the specified 
relation. Inconsistency between FDLIST and relation directory." 

Go to Step 5. 
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Step 21 : Construct data structures PDIJLAG 23 d CMFLDS. Is No. of common 
field = 1? If yes go to Step 22, else go to Step 24. 

Step 2°: Is the updating operation deletion? If yes go to Step 27, else 
go to Step 23. 

Step ??: Gi-e message, "Only primary key common between user^ile ond 
specified relation." Go to Step 5. 

Step 24 : Is No. of common field = totdL No. of fields in us c r file? If 
yes go to Step 27, else go t o Step 25. 

Step 25: Give message, "All the fields specified in user file arah vusi- 
present in specified relation. Shall I proceed?" 

Step 26: If reply = yes, go t o Step 27, else if reply = No go to "Step 5, 
else go to 'Step 25. 

Step 27; Read various informations about relation E31CD fmom relation 

directory and calculate MAXRC, maximum no. of records in a sector. 

Step 28: Is updating operation deletion 9 If yes go to Step 29^1 se go to 
Step 30. 

Step 29: Call subroutine DELETE. Go to Step 33. 

Step 30 : Is updating operation insertion? If yes go to Step 31, else ' 
go to Step 32. 

Step 31 : Call subroutine INSERT. Go to Step 33. 

Step 32: Call subroutine MODIFY. Go to next step. 

Step JT \ Updating is based on singLe re Hi on? If- yes goto Step 34, 
else go to Step 36. 

Step 34 : Is operation deletion? If yes go to Step 46 , elsfe stop. 

Stpp ^5 : Assume relation No. = 0 and store it in RELCD. 

Step 36: Incremett RELCD by 1 . 

Step 37: Is RELCD 39. If yes, go to Step 34, else go to Step38. 

Step 38: Check from re It ion directory whether relation EEDfeD exists 
in D^ta Base. If yes go to 3-fcsP 39, else go to Step 7 6. 

Step 39 •• Prom relation directory check whether primary key o^ user file 
matches. If yer^ go to Step 40, else go to Step 36. 
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Step 40 : 

Step 41 : 
Step 42 : 
Step 43 s 

Step 44: 
Step 45 : 
Step 46 : 


Prom relation lirectory check whether f^oim-t of primary 
key of user file matches. If yes, go to Step 4% else 
go to Step 36. 

Check whether the relation exists in FDLIST. If yes go to 
Step 43 , else go to Step 42. 

Give message, "Relation dijeectory and PDLIST are inconsist ant" 
Go to Step 36. 

Check -from PDLIST whether there is any -field common between 
user file and fields present in this relation. If yes go to 
Step 44, else go to Step 42. 

Construct data structures PDFLAGond CMFLDS, In No. of common 
field = 1? If yes, go to Step 45, else go to Step 27* 

relat i on ? 

Is updating operation dele-rfaLon?^ If yes, go to Step 27, else 
go to Step 36. 

Is operation Special modification? If yes go to Step 6 of 
Phase I algorithm^ else Stop. 


Dnd of Algorithm, 

A brief account of different subroutines written to implement this 


algorithm is given below: 

(l ) Subro- tine CCHRLD (compare Relation Directory)- 

This subroutine compares primary key of user file and its format 
with corresponding entries in relation directory for a given relation 
No. RELCD. If primary key matches it sets a fig PKPLAG and if its 
format also matches it sets a flag PI1P1AG, else both flags are reset. 
Calling instruction is 3113 R2, COi.iRL D. 

(2) Subroutine EEADRD (Read Relation Director) 

This subroutine reads various entries in relation directory corres- 
ponding to relation No. H3LCD. Calling instruction is JI.1S R2, HFADRD. 
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(3 ) Subroutine CQHVRP (Convert Reply) 

This subroutine converts a number stored in ASCII code in a buffer 
EEPIY of si^e 6 bytes to binary code and stores it in a word. 

Example : 

MS R2, COFVEP 
WORD RELCD 
REPLY : WORD 6,0,2 
BYTE 61,62 
. = . + 4 
RELCD : . = . + 2 

Content of RELCD will be 12. 

( 4 ) Subroutine COMMPC (Common Field Check) 

This subroutine checks whether a relation number RELCD exists in 
EDLIST. If it exists, it sets a flag CMFLFL. Also if RELCD exists in 
EDLIST, it compares fields of user file with fields present in relation 
RELCD, and their formats, and ccrrespondingly it constructs data struc- 
tures EDELAG- and CMPLDS. It also stores total number of common fields 
in KCOMFL. Calling instruction is JE1S R7, C01MFG . 

In the next few chapters, algorithms fat? insertion, modification 
and deletion operations have been described. This will complete proces- 
sing phase of updating operation. Symbols used in these algorithms have 
the following interpretations : 

HEECP = Serial No. of record. currently being processed in user file . 
OVERCY = Overflow cylinder number corre ponding to relation RELCD, 
currently being updated. 

ASLOCP = Pointer to starting location of primary key vaLue in a record 


in sector 
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SLOCR = 
UPDATE = 

OVERS' = 


NACTRS = 


ACTLRC = 
NTIMED = 
MaXBO = 
COUNT 6= 
BSLOCP = 
ACTLEL = 
MIN 

SINTL = 
PINT! = 


iointer to storting location of a record in sectors. 

A flag which when set indicates that at last one record has 
been updated in the sector currently read. 

A flag which when set indicates that currently updating is going 
on in the overflow area. 

Mo. of records in sector already tested for primary key value 
matching. 

Total No. of records in user’s file. 

No. of records updated in the sector currently read. 

Maximum possible number of records in a sector. 

A counter which counts number of records in sector currently read. 
A pointer which points at the starting of a record in user file. 
Length of a record in user file . 

No. of records in primary index table. 

Secondary index table record-length. 

Primary index table record-length. 
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Flowchart for Processing-Phase 
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5- DELETION 


Deletion is an updating operation where sane records from, a relation 
or a group of relations are deleted. V/hen records are deleted from a sin- 
gle relation, it is called single relation deletion and when they are dele- 
ted from a group of relations it is group relation deletion. Eor perso- 
nnel data base, example of single relation deletion is a situation where 
it is observed that due to sane reasons, informations stored in a relation 
are no longer relevant for a person and example of group relation deletion 
is a situation where a person leaves the organization. 

In deletion operation, user file consists of only one field, the 
primary key of user file. If more than one field is specified all the 
other fields except the first one will be neghcted. A sample user file 
is given below - 

Personnel No. 

IC-00050 

IC-Q0060 

IC-00065 

Before giving algorithm for delete operation, a brief description of 
a few subroutines, written to implement this algorithm is given sd that 
the algorithm can be presented more easily. 

Subroutine READ (Read a Secetor) 

This subroutine stores the contents of a sector in an assigned 
area in core memory. 
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Example - 

JMS R4, READ 
WORD CYLNDR 
WORD SURSEC 
WORD AREA 
CYLNDR: WORD 100. 

SURSEC: WORD 1 
AREA : . = .+400 

Contents of Sector No. 1 of cylinder No. 100 will be stored in AREA. 
Subrou tine W RITE (Write on a Sector) 

This subroutine stores the contents of an area of size 256 bytes in 
a sector. 

Example - 

JMS R4, WRITE 
WORD CYLNDR 
WORD SURSEC 
WORD AREA 
CYLNDR: WORD 50. 

SURSEC: WORD 2 
AREA : . = .+400 

Contents of AREA is transferred to second sector of cylinder No. 50. 
Subroutine TRSUSE (Track, Surface, Sector) 

Given a primary key value as input, this subroutine searches primary 
and secondary index tables to find cylinder number and surface -sect or 
address in which a record of this primary key value should exist. 

If primary index table search is successful, it sets a flag MTCHPR 
else it is reset. If secondary index tabLe search is successful it sets 
a flag MTCHSR else it is reset. If both searches are successful, it 
stores cylinder number ifi CYLNDR, total number of records in secondary 
index table in 1RECSE, surface -sect or address in SURSEC, total number a£ 
records in this sector in NEECST. Assuming first record of index tables as 
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0"bh.j record, this subroutine stores the record number of primary index 
tnble at which matching took place in COUMTG , record number of first 
secondary index table in COURT 1 and record number of subsequent secondary 
index table in C0UNT3. 

Example - 


TSR/=PKY7AL, SLOCP 
JMS R3, TRSUSE 
WORD SLOCP 

PKYVAL : BYTE 'I, 'C, 40,60,60,60,62,60 
SLOCP : . = . + 2 

Subroutine C01CPEQ (Compare for Equality) 

This subroutine compares contents of two areas for equality. If 
equal, it sets a flag EQELaG else it is reset. 

Example - 


TSR /ARSA1 , LOCI 
TSR/AREA2, L0C2 
JMS R2, COMPEQ 
WORD LOCI 
WORD L0C2 
WORD SIZE 

ARE At :BYTE 'I, 'G, 40, 60, 60, 60, 62, 60 
AREA2 :BYTE 'I, '0,40,60,60,60,62,60 
SIZE : WORD 8.; size to be compared. 

In this case EQELAG is set. 

Subroutine BLANKA (to Blank Area) 

This subroutine puts blanks in a given area. 

Example : 

TSR/BUE1, SLOC 
TSR/10., SIZE 
JMS R2, BLANKA 

WORD SLOC; starting location 
WORD SIZE 

BUF1 : . = . + 100 

SIZE : . = . + 2 

Contents of first 10. bytes of BUE1 will be blanks. 
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Subroutii e SUSjg (Surface-Sector) 

Given a primary key value and cylinder number of a cylinder in which 
a record corresponding to this primary key value exists, this subroutine 
searches secondary index table. Xf search is successful it sets flag 
MTCHSR and stores furfiace— sector number in SURSEC. This subroutine is 
a part of subroutine TRSUSE. 

Example - 

TSR/ PKYVAL, S10CP 
JUS B3, SUSE 
WORD SIOCP 

PKYVAL : BYTE 'I, '0,40,60,60,60,62,60 
SIOCP : . = . + 2 

Algorithm for delete operation is as follows - 
Step 1 : Initialization, NEECP = 0; Find OVERCY. 

Step 2: Initialize ASLOCP, S10CR; Reset flags UPDATE and OVERF; NACTRS=0; 
NEECP » NRECP+1 . 

Step 3 ‘ Is NRECP >• ACTIRC? If yes go to Step 4; else go to Step 5, 

Step 4 : Return to calling program. 

Step 5 : Print record No. NRECP and call subroutine TRSUSE. 

Step 6: MTCHPR = set? If yes go to Step 9; else go to Step 7- 
Step 7 s Give message, "Primary Index Table Search fails". 

Step 8: Take next record in user's file. Go to Step 2. 

Step 9 : MTCHSR = set? If yes go to Step 11 ? else go to Step 10. 

Step 10: Give message, "Secondary Index Table search fails". Go to Step 8. 
Step 11 : Is NREOST = 0? If yes go to Step 12; else go to Step 13. 

Step 12: Give message, "Record does not exist in sector". Go to Step 8, 
Step 13 :NTTMED = 0. 

Step 14: Read sector SURSEC of cylinder No. CYLNDR. 
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Step 15: C0UNT6 = 0. 

Step 16: COUNTS = C0UNT6+1 . 

Step 17: Is NACTRS <' NRSCST? If yes go to Step 18; else go to Step 28. 

Step 18: Is C0UNT6 MAXRC? If yes go to Step 23? else go to Step 19. 

Step 19: Check whether primary key value is blank of current record in 
sector. If yes go to Step 22; else go to Step 20. 

Step 20: NACTRS = NACTRS+1 . Compare primary key values of this record 
and user file record. Are they equal? If yes go to Step 21 ; 
else go to Step 22. 

Step 21 : Delete current record in sector. Set UPDATE flag. NTIMED = 

NITEMD +1. 

Step 22: Consider next record in sector. Go to Step 16. 

Step 23: Is flog UPDATE = set? If yes go to step 24? else go to Step 25. 
Step 24: Write back sector. 

Step 25: Is OVERCY = 0? If yes go to Step 26; else go to Step 27. 

Step 26: Give message, "Secondary index table inconsistent." Go to Step 28. 

Step 27 : Prom last two bytes of current sectors read pointer to overflow 
sector. Set OVERF flag. Initialize AS10CP, SLOCR. Read over- 
flow sector. Go to Step 15. 

Step 28: Is UPDATE = set? If yes, go to Step 29; else go to Step 12. 

Step 29: Write back sector. Update secondary index table. 

Step 30 : Compare primary key value of user file record with highest 

primary key entry in current record of secondary index table. 

Are they equal? If yes go to Step 33; else go to step 31 • 

Step 31 : Write back secondary index-table. 

Step 32: Give message, "Record Processed". Go to Step 8. 

Step 33: C0UNT3= C0UNT3+1 

Is the current record of secondary index table last record? 

If yes go to Step 38; elss go to Step 34. 

Step 34: Is primary key value of record No. CDUNT3 in secondary index 
table 3^ primary key value of user file-record? If yes go to 
Step 35; else go to Step 31* 
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Step 35 : Head SURSEC and ERECST from current record of secondary index table. 

Step 36: Is ERE C ST = 0? If yes go to Step 30; else go to Step 37. 

Step 37: Initialize ASLOCP, SLOCR; EACIRS = 0, ETIMED = 0; go to Step 14. 

Step 38: Write back secondary index table. C0UED1 = C0UI7T+1 . Read secondary 
index table from first sector. Is highest primary key entry in 
record Eo. C0UNT1 blank? If yes go to Step 39, else go to Step 40. 

Step 39: Read NRECSE and SURSEC from current record in secondary index 

table. Read secondary index- table from sector SURSEC. C0UHT3 = 0. 
Go to Step 34. 

Step 40: COUNTO = COUlffO+1 

Is COUNTO = NIN? If yes, go to Step 32; else go to Step 41. 

Step 41 : Is highest primary key values entry in current record of primary 
index table ^ primary key value of user file record? If yes go 
to Step 42; else go to Step 32. 

Step 42: Read CYliEDR, NRECSE from current record of primary index table. 

_ „ . ’ 1 . Call subroutine SUSE to find 

SURSEC. MTCIISR = set? If yes, go to Step 36; else &o to Step 32. 


End of Algorithm. 
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Flowchart for DELETE 
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i UPDATE, OVERP; I&CTRS = 0 


-i- 


BEIOCP = BSIDOP 
+ACTLRL 


{ Is HRECP y ACTLRC 


Yes 


RETURN 


I No 


r. No / PRINT RECORD NO. NEE CP. JUMP TO X 

^ oa f„ l'*"' '\ TRSUSEMTCHPR = set? 

fails " 

_ 


No 


Yes 

1 / 


MTCHSR = set? ? 
\ / 


Yes 


Record does 

| Yes 

_/ NRECST = 0? 

not exist in 


*v ... 


sector 





/ ;i 


No 


[ NTIMED=0 ! 

nr "i 


i* j 
' 


\ / 
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/'is UPDATE = set?\ 
/' 


No 
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Ncl 


t 

"\ 


Write back secondary index table; 
C0UNT1 = C0UNT1 +1 | Bead secondary 
index table; check record no. 
COUNT 1 in secondary index table 
for blank. Is it blank? 


\ 


\ 



Yes 

i 

Calculate NRECSE, SURSEC. Read 
secondary index table C0UNT3 = 0 


H 


/ COUNTO = COUNT 0+1 \ 
Is COUNTO= MIN? y 


Yes 



No 




6. MODIFICATION 


Modification is an updating operation where values of different 
fields o-f some records are modified. When this operation is perform- 
ed on o single relation it is called single relation modification and 
when it is performed on all the relations it is called group relation 
modification. For personnel data base, example of modification opera- 
tion is a situation when some persons get promotion and their ranks 
and salary are to be updated. If all these fields except the primary 
key occur only in one relation it is single relation modification and 
if these fields occur in more than one rel ition or different relations 
it is group relation modification. 

In modification operation usar file consists of primary key and 
the fields to be modified. A sample user file is as follows - 


Personnel No. 

Rank 

Salary 

Qualif . 

IC-00050 

IC-OOO 56 

IC-001 1 0 

CAPT. 

MAJOR 

* 

1600 

1400 

i 

j * ! 

* 

Ma 0 A . 

M.Tech. 


Symbol * (star) »s value of a field indie xtes that 
value of this field remains unmodified for the corres- 
ponding primary key value. 

Algorithm for modification is similar to algorithm for deletion 
except a minor change that instead of deleting a complete record, 
values o 4 ’ different fields are modified. Subroutines used in modi- 
fication operation are aleady explained in previous chapters except 
the following - 
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(l ) Subroutine TRAITS (Transfer) 

This subroutine transfers the contents of an area, of a specified 

size with specified starting location to another area whose starting 

location is specified. Example - 

T SR /SOURCE, IOCS 
TSR/DESTF, 10CD 
JMS R5, TRANS 
WORD LOCS 
WORD LOCD 
WORT' SIZE 

SOURCE : BYTE 1,5,9., 10., 12, 4 
DESTF : . = » + 1 00 
SIZE : WORD 4 

Contents of first 4 bytes of DESTR will be 1,5>9., 10. respectively. 
( 2 ) Subroutine TRATTR (Transfer attributes) 

This subroutine modifies a complete record. Elowchnrt for this 
subroutine is given below. 


( Subroutine TRATTR )> 



Calling Instruction of this Subroutine is JMS R2, TRATTR. 
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Algorithm for modification operation is as follows - 

Step 1 : Intialize HFJ3CP = 0, find overflow cylinder number corresponding 
to relation RELCD and store it in OVEECY. 

Step 2: Initialize ASLOCP, SLOCR. Increment REE CP by 1 . Reset flogs 
UPDATE j OVEEE. Initialize HACTRS = 0. 

Step 3 ' Is HKECP> ACTLRS? If yes go to Step 4; else go to Step 5. 

Step 4: Return to calling program. 

Step 5 • Print record number HEEECP and call subroutine TR3USE. 

Step 6: MTCHPR = set? If yes go to Step 9? else go to Step 7* 

Step 7: Give message "Primary index table search fails." 

Step 8: Take next record in user’s file. Go to Step 2. 

Step 9: MTCHSR = set? If yes go to Step 11s else go to Step 10. 

StepIO: Give re ssage "Secondary index table search fails". Go to Step 8. 
Step 11: Is RRSCST = 0? If yes go to Step 12? else go to Step 13- 
Step 12 : Give message "Record does not exist in sectbor". Go to Step 8. 
Step 13 : Read sector SURSBO of cylinder number CYDHDR. 

Step 14-* COURT 6 = 0. 

Step 15: COURT 6 = COURT 6+1. 

Step 16: Is MACTRS < NRSGST? If yes go to Step 17? else go to Step 27. 

Step 1 Jt Is C0UHT6> MAXRC? If yes go to Step 22? else go to Step 18. 

Step 18: Check whether primary key value is blank in current record of 
sector. If yes go to Step 21? else go to Step 19. 

Step 1 9 : NACTRS = HACTRS + 1 . 

Compare primary key value of this record and that of current 
record in user file. Are they equal? If yes go to Step 20; 
else go to Step 21 . 

Step 20: Call subroutine TRATTR to modify this record and set flag 
UPDATE in case there is any modification. 
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Step 21 : Consider next record in sector. Go to Step 15, 

Step 2P : Is flog UPDATE = set? If yes go to Step 23; else go t o Step 24. 
Step 23: Write back sector. 

Step 24: Is OVERCY =0? If yes go to Step 25 j else go to Step 26. 

Step 25: Give message "Secondary index table inconsistent". Go to Step 27- 

Step 26: Set flog OVER]?. Prom 1st two bytes of current sector read 

pointer to overflow sector. Initialize ASLOCP, SLOCR. Read 
overflow sector. Go to Step 14. 

Step 27: Is UPDATE = set? If yes go to Step 28? else go to Step 12. 

Step 28: Write back sector. 

Step 29: Compare primary key value of current record in user file with 
highest key entry in current record of secondary index table. 

Are they equal? If yes go to Step 31 ? else go to Step 30. 

Step 30: Give message, "Record processed". Go to Step 8. 

Step 31 : C0UUT3 = COUNTS +1 . 

Is the current record of secondary index table last record? 

If yes go to Step 36? else go to Step 32. 

Step 32: Is primary key of current record in user file highest key 
entry in record No. C0UNT3 of secondary index table? If yes 
go to Step 33; else go t o Step 30. 

Step 33: Re >d SURSEC, NRfiCST from secondary index table. 

Step 34: Is NHECST = 0? If yes go to Step 29? else go t o Step 35- 

Step 35: Initialize ASLOCP, SLOCR. Initialize, MCTRS = 0. Go to Step 13. 

Step 36: C0UNT1 = C0UNT1+1. 

Read secondary index table from first sector of cylinder number 
CYLNDR. Is highest key value entry in record number (J0UNT1 blank? 
If yes go to Step 37? else go to Step 38. 

Step 37: Read NEECSE and SURSEC from current record in secondary index 

table. Read secondary index table from sector SURSEC. Initialize 
C0UNT3 = 0. Go to Step 32. 
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Step 38 : COUEPO = COU1WO+1 . 

Is COUEDO = EOT? If yes go to Step 30; else go to Step 39- 

Step 39: Is highest key entry in current record of primary index table 
^.primary key value of current record in user file? If yes 
go to Step 40; else go to Step 30- 

Step 40: Read CYLiTDR, HEECSE from primary index table- Call subroutine 

SUSfi to find SURSEC. Is flag MTCHSR = set? If yes go to Step 34 
else go to Step 30. 


End of Algorithm. 
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Flowchart for Modification 


Subroutine MODIFY 


\ 


| HHEGP = 0; Find OVERCY 



i Re turn; 

I 1 









! Read sector SDRSEC from CYIiHDR j 


COUNTS = 0 ; 

1 l 

4r 

COUNTS = COUNT6+1 I- 


B 


Is NACTRS HHBCST?j> 


Yes 



i No 

t 

“'Set OVERT; Find SURSBcT 

Ird.tio.Iize AS3DCP , SIDCR» 
Read overflow area. 


1 . 1. r. 

ZMN UtA 
\ 7 

Vu v 


KANPUR 
i. i ;.!Rary 

5192 2 








52 


\ Is UPDATE = set? 


Write back sector j 


Is primary key value of current 
record = Highest key entry in 
current record of secondary 
indeed table? 


’Record t 
processed”! 


Yes /~ \ 

Q / Is it last entry of secondary N 

\ index table? ^ 


j — No 


Call subroutine COMPRI; 
MATCHE = set? 



Read SURSEC, IRECST 



<^HRECST = 0?^> 



Initialise ASIiOCP, SIDCR; 
STACTRS = 0. 
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Read pr imar y index table and call SUSE 
to find SURSEC 






7. IHSEEOIQET 


Insertion is an updating operation where sene new records are 
inserted in data base, When records are inserted in a single rela- 
tion, it is single relation insertion and when they are inserted in 
more than one relation, it is group relation insertion. A sa 
user file for insertion operation is as follows - 


Personnel No. 

Rank 

Salary 

Qualification 

IC-00050 

IC-OOO 56 

IC-001 1 0 

CAPT. 

MAJOR 

* 

.... 1 

1600 

1400 

* 

* 

M.A • ‘ 

M.Tech. | 

i 


If all the fields specified in user file except the primary key 
occur only in one relation it is single relation insertion and if they 
occur in different relations or more than one relation it is group rela- 
tion insertion. Symbol * (Star) as value of a field indicates that value 
of this field is left blank for the corresponding primary key while 
inserting this record. Different subroutines used in insertion opera- 
tion are explained in previous chapters except the fallowings: 

(l ) Subroutine ALLOCT (Allocate a Cylinder) 

This subroutine finds out cylinder number of the first available 
empty cylinder in disk starting from cylinder number 0 and stores it in 
OVERCY. This cylinder is used as overflow cylinder. Calling instruction 
is JMS R4, ALLOCT. 
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(2 ) Subroutine BDCTSBC (Next Sector) 

This subroutine finds the sector number of a sector next to sector 
number SUHSEC and stores it in NEWSS. Calling instruction JMS R4, NXTSEC. 

(3 ) Subroutine PUT 

This subroutine writes back primary index table on disk. Calling 

instruction is JM3 R , PUT. 

Algorithm for insertion operation is given below: 

Step 1 : Initialize NRECP = 0. Pind overflow cylinder number corresponding 
to relation RSICD and store it in OYERCY. 

Step 2: Initialize ASLOCP, SIOCR. Increment NRECP by 1. Clear flags 
FOUND®* 5 OVERT* , PINDXF. 

Step 3: Is NRECP > ACTIRS? If yes go to Step 4; else go to Step 7. 

Step 4: Is PINDXF flag set? If yes go to Step 5? else go to Step 6. 

Step 5: Write back primary index table on disk. 

Step 6: Return to calling program. 

Step 7 - Print Record No. NRECP. 

Step 8: Call subroutine TRSUSE to find cylinder and sector no. 

Step 9: Is MTCHPR = set? If yes go to Step 11? else go to Step 10, 

Step 10: Set PINDX flag. Transfer primary key value of current record 
in user file to the last record in primary indexable. Go to 
Step 8. 

Step 11 : Is MTCHSR = set? If yes go to Step 13? else go to Step 12. 

Step 12: Transfer primary tey value of current record in user file to 
last record in current secondary index table. Goto Step 8. 

Step 13: CRNTCY-*- CYRNDR. 

Step 14: Read sector no. SURSEC froa cylinder no. CYINDR. 

Step 15: C0UNT6 = 0. 
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Step 1 6 : C0UHT6 = C0UFT6+1 . 

Step 17s Is C0UHT6 ^MaXRC? If yes go to Step 26; else go to Step 18. 

Step 18 s Is prim iry key value in current record of sector blank? If yes, 

go to Step 22; else go to Step 19. 

Step 19s Is primary key value of current record in sector = primary key 

value of current record in user file? If yes go to Step 20; else 

go to Step 21 . 

Step 20: Set Flag FOUFGF. 

Step 21 : Update ASLOCP, SLOCR. Go t a Step 16. 

Step 22: Transfer current record in user file to current record in sector. 
Write back sector on disk. 

Step 23 s Update secondary index table and write it back on disk. 

Step 24: Give message, "Record processed." 

Step 25: Take next record in user file. Go to Step 2. 

Step 26: Initialise ASLOCP, SIOOR. Is OVERCY = 0? If yes, go to Step 29; 
els go to Step 27. 

Step 27: Read la st 2 bytes of sector and store it in HEWSS. Is HEWSS = 
20040? If yes go to Step 29; else go to Step 28. 

Step 28 : CRNTCY”^ CYLEDR 
SURSEC «*- HEWSS. 

Set flag OVERF. Read sector no. SURSEC from cylinder CRHTCY. 

Go to Step 15- 

Step 29: Is flag FOUEDF = set? If yes go to Step 42; else go to Step 30, 

Step 30: Set flog OVERF. Is OVERCY = 0? If yes go to Step 37; else go to 
Step 31 . 

Step 31 : Read first sector from cylinder OVERCY. Read first 2 bytes of 
this sector into HEWSS. Is HEWSS = last sector of a cylinder? 

If yes, go to Step 32; else go to Step 33* 

Step 32: Give message "Ho empty sector available in overflow cylinder". 

Go to Step 25- 

Step 33: Find out next available sector in overflow cylinder and store it 
in HEWSS. 
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Step 34s Store NtSWSS in first two bytes of first sector of overflow 
cylinder. 

Step 35 : Store HEY/SS to last two bytes of sector SUBSEC o-p cylinder 
CRNTCY. 

Step 36: SURSEC -*-HEWSS. 

Pill up sector are j. with blanks. Go to Step 22. 

Step 37 : Find out the first available empty cylinder in disk. Is it 
available ? If yes go to Step 3'9; else go to Step 38. 

Step 38: Give message, "No empty cylinder availhle in disk". Go to Step 25- 

Step 39: Store cylinder no. cf newly available cylinder in OVERCY. Store 
OVERCY in relation directory. Store 2 in last 2 bytes of sector 
SURSEC of cylinder no. CYDNDR. 

Step 40: SUfiSEC-^- 1 

Pill up sector area by blanks. Store 2 in first two bytes of 
first sector of cylinder OVEBCY. 

Step 41 : Pill up sector area by blanks. SJRSEC-t- 2. Go to Step 22. 

Step 42: Comp -re primary key value cf current record in user file with 
highest key entry in current record of secondary index table. 

Are they equal? If yes go to Step 43; else go to Step 30. 

Step 43: C0UNT3 = C0UNT3+1 . 

Is the current record of secondary index table last record? 

If yes, go to Step 46 ; else go to Step 44. 

Step 44: Ishighest key entry in current record of primary index- table 
primary key value. of currant ^ ye c ord in user file? If yes 
go to Step 45l else go to Step 30. 

Step 45: Read SURSEC from secondary index table. Go to Step 14. 

Step 46: G0UNT1 = (HJNT1+1. 

Read secondary index table from first sector of cylinder no. 
CYIiNDR. Is highest key value in record no, C0UNT1 blank? If 
yes, go to Step 47; else go to Step 48 , 

Step 47: Read SURSEC from secondary index table. C0UHT3 =0, Go to 
Step 44 ♦ 

Step 48: COUNT 0 = COUNTO + 1 , 

Is COUNTO = NIN? If yes go to Step 30; else go to Step 49 . 



Is highest prim uy key entry in current record cf primary 
index tabled primary key value of current reford in user 
file? If yes, go to Step 50, else go to Step 30. 

Read CYIRDR, HRE5CSE from primary index table. Call sub- 
routine SUSE to find SURSEC. Is flag M.1CHSR = Set? If 
yes, go to Step 13? else go to Step 30. 


End of Algorithm 



Flowchart for Insertion 


< SUBEOTJTIlffi INSERT \ 

\ / 


Z1 ^ 

I KRECP = 0; Find OVERCY j 



J Initialise ASIOCP, SIDCRj 
j clear FOUNDF, OVERF 
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0VBRCY =0?~^ )-- 


Yes 


Ho 


Read last 2 bytes from 
SCTRAR in HEWSS 


CRHTCY=OVBRCY r 
SURSEC=HEWSS | 


.Ho 


/ \ 

\ HEWSS = 20040 ; 


Set OVERE 


l 


Yes 


j 

Read sector 

iSURSEC from 

| CRHTCY 


\ I 


No 


/ 

BOUKDE = 

\ 

\ 

set? y 

1 

~ KoT ,<3 “ 
1 


L B 


J OVERCY = 0? ‘ y 

/ 


Yes 



E 


Read 1st sector of 
OVERCY. Read 1 st 
word and store it 
in HEWSS 


¥ 


'' 4 .. . 


HEYfSS = Last sector \ 
of cylinder? / 

f 

Ho 


Call HXTSEC and store in 
HEWSS 


.Yes 


"No space available 
in overflow cylinder" 




Store HEWSS in 1st word and write it back 
in first sector of OtERCY. Read sector 
SURSEC from cylinder CRITCY and store 
HEWSS in last 2 bytes and write it back. 
SURSEC = HEWSS 
Make SCTRAR blank. 
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yes 


f 


Store OVERCY in Relation Directory. 
Stare 2 in last 2 bytes of SCTRAR 
and write it back in sector SURSBO 
of CYLEDR. SURSEC = 1 
Blank SCTRAR and put 2 in first 2 
bytes. 7/rite back SCTRAR in secdnr 
SDRSEC of OVERCY. Blank SCTRAR. 
SURSEC = 2 


1 ? 



11 Eo cylinder 
available” 


f 
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r 

jL 


Update secondary index table and 
write it back. "Record processed"* 
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/ Compare primary key value with \ 
secondary index table entry. 

\ Are they equal? , 


$Yes 


Is it last entry of secondary \. 

index table ? / 


yes 


No 



IL 

\ 


No 


'Gall OQMPRI \no 
, MATCH3?=Set ? / 


fees 


C0UNT1 = C0UNT1 + 1 
Read secondary index table? check 
next entry for blank. 


Read SURSEC from 
secondary index table 


r kj 


\ _ 

/ Is it blank? 


y Yes 


Calculate SURSEC. Read 
secondary index table. 
C0UNT3=0 









8. RiSZJIlTS and DISCUSSIONS 


For updating operation, SCaN subroutine and all the pregram 
subroutines described so far are to be loaded into memory. SCAl'T 
occupies memory location from 30000 to 46234 and rest of the program, 
subroutines occupy memory location from 54000 to 110500. After load- 
ing, execution is to be started from address 54000. 'Then execution 
of Phase-I is over, control automatically transfers to Phase-II. 

Typical examples of different messages received in Keyboard 
while updating program is being executed are given on • the 
next page. 

Discussion 

Algorithms written for modification and insertion operations 
have the following limitations : 

In single-relation modification, all the fields which are common 
between specified relation and user-file are being updated in the 
specified relation only. If these fields exist in any relation other 
than the sp3cified one, this will lead to discrepancy in data base. 

So before processing single-relation modification operation, it should 
be checked from FDUST that such a situation does not arise. Horever, 
if such a situation arises, processing should not stop but it should 
automatically transfer to group-relation modification operation. 

On the other hand, in group-relation modification, it may happen 
that a field specified in user file exists in more than one relation 
having di^ mat primary keys. According to the algorithm for group- 
relation modification this field will be modified only in those relations 
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OPERATION ST ffiTS, SPECIFY TYPE OP JOB 

POR UPDATING MESS U 

FOR RETRIEVAL PRESS E 

POR DBA PRESS D 

THEN GIVE LIFE FECDU 


ABC 


GIVE IDEFTIPICATDF CODE 


GIVE INPUT JUDICJM 
POR CARD READER PRESS C 
POR KEYBOARD PRESS K 
TH. JIT GIVE LIFE FEHDC 


SPECIFY US R PILE WITH PRIMARY KEY AS FIRST ENTRY 


FOLLOWING TABLE PRINTS USER FILE 
FIRST COLUMN GIVES FIELD CO DSD. 

SECOND COLUMN GIVES FIELD LENGTH 

THIRD COLUMN GIVES DISTANCE IN DaTA CARD 

FOURTH COLUMN GIVES DISTANCE AFTER REMOVING FILLERS. 

FIFTH COLUMN GIVES FORMED CODE. 

pi 8. 0. 0. 

F 45 8. 60 . 8. 

p 25 6. 108 . 16. 

IS IT O.K.? 

SPECIFY INPUT MEDIUM FOR DATA 
C 

CARD-READER READY? 


050010 
030010 
03 0006 


RECORD NO . 1 . , ACCEPTED AND 

RECORD NO. 2 ACCEPTED AND 

RECORD NO. 3 ., ACCEPTED AND 

RECORD ID. 4 ACCEPTED AND 

RECORD NO . 5 • > ACCEPTED AND 

RECORD NO. 6., ACCEPTED AND 

END OF DATA 

ID . OF RECORDS IN USER FIIE 
**PHASE-I OVER** 

SPECIFY TYPE OF UPDATING 

CODE IDR DSLST=D, INSERTS , MODIFY 


STORED 

STORED 

STORED 

STORED 

STORED 

STORED 

6 . 


=M 


SPECIFY WHETHER UPDATING IS OF SINGLE 
SINGLS=S > GROUP=G 

S 

SPECIFY REMTION CODE 


RELATION CR GROUP OF 


RELATIONS 


ALL SPECIFIED FIELDS ARE NOT PRESENT IN GIVEN RELATION 
SHALL I PROCEED? 


RECORD NO . 
RECORD NO. 
RECORD ID. 
RECORD NO. 
RECORD NO. 
RECORD NO. 


1 ., PRC CESSED 

2 ., PROCESSED 

3 ., PROCESSED 
4., PROCESSED 

5 ., PROCESSED 

6 .. PROCESSED 



.Example -2 
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OPERATION STARTS, SPSCITT TYPE Op JOB 

FOR UPDATING PRESS U 

FOR RETRIEVAL HIE S3 R 

FOR DBA PRESS D 

THEN GIVE LINE FSEDU 


ABC 


GIVE IDENTIFICATION CODE 


GIVE INPUT MEDIUM 
FOR CARD READER PRESS C 
FOR KEYBOARD PRESS K 
THEN GIVE LINE FEEDK 


SPECIFY USSR FILE RITE PRIMARY KEY AS FIRST ENTRY 
22 PNUM FI X*8 . 

00 


FOLLOWING TABLE PRINTS USER FILE 
FIRST COLUMN GIVES FIELD CO IE. 

SECOND COLUMN GIVES FIELD LENGTH 

THIRD COLUMN GIVES DISTANCE IN DATA CARD 

FOURTH COLUMN GIVES DISTANCE AFTER REMOVING FILTERS. 

FIFTH COLUMN GIVES FORMAT CODE 


IS IT O.K.? 


SPECIFY INPUT MEDIUM FOR DATA 
K 

GIVE INPUT DATA FROM KEY-BOARD 

IC 00030 

RECORD NO . 1 . , ACCEPTED AND STORED 

IC 00040 

RECORD NO . 2 ACCEPTED AND STORED 


END OF DATA 

NO . OF RECORDS IN USER FILE ' 

**PHASE-I OVER** 

SPECIFY TYPE OF UPDATING 

CODE FOR DELET=D,INSERT-I,MODIFY=ffi 


SPECIFY WHETHER UPDATING IS 


ON SINGLE RELATION OR 


GROUP OF RELATIONS 


SINGLE=S, GROUP=G 
G 


*#*-**kel. TION no. 
RECORD NO. 1 

RECORD NO. , 2 ., 

****-*REL AIIO N NO. 
RECORD NO. 1 . , 

RECORD NO . 2 . , 


30 RD DOES NOT EXIST IN SECTOR 


30RD DOBS NOT EXIST IN SECTOR 
30 RD DOES NOT EXIST IN SECTOR 
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whose primary key is the same as primary key of user file. This may 
again lead to discrepancy in data ta se . Hence after a group— relation 
modification is over, it should be checked from FDLIST whether such a 
situation arises and if it does, processing should not stop but it 
should repeat itself and ask for a user file with different primary 
key. 

While inserting a record it is never being checked whether the 
■field-values inserted in a relation for a given primary key are con- 
sistent with field values for the same primary key in the same rela- 
tion or other relation. As a result, it may semetime happen that 
for Hie same primary key there may be records with different field- 
values for a single-valued field, creating discrepancy in data base. 
This can be avoided if all these field values for given primary keys 
are ietrieved from data base before starting insertion operation and 
manually verifying that there is no inconsistency between retrieved 
information and informations going to be inserted. This verification 
can also be done by writing a program. 

Removing all these limitations of Modify and Insert algorithms 
and ma V-i ng these algorithms more flexible and more realistic may be 
a further extension of this work. 
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